Sharing continous glucose data and reports

ABSTRACT

In some example embodiments, there is provided a method, which includes sending a message to a server, wherein the message includes a request for a share code to enable another user to access, via a first computer, analyte data obtained from a host-patient associated with a receiver and/or an analyte report for the host-patient associated with the receiver; receiving, in response to the sending, the share code generated by the server, wherein the share code comprises a checksum portion, a password portion, and an identifier portion indicative of the host-patient; generating a user interface view including the share code; and displaying the user interface view including the share code, wherein the share code enables the other user to access, via the first computer, the analyte data and/or the analyte report. Related systems, methods, and articles of manufacture are also disclosed.

INCORPORATION BY REFERENCE TO RELATED APPLICATIONS

Any and all priority claims identified in the Application Data Sheet, orany correction thereto, are hereby incorporated by reference under 37CFR 1.57. This application claims the benefit of U.S. ProvisionalApplication No. 62/247,040, filed Oct. 27, 2015. The aforementionedapplication is incorporated by reference herein in its entirety, and ishereby expressly made a part of this specification.

TECHNICAL FIELD

The present disclosure generally relates to continuous glucosemonitoring.

BACKGROUND

Diabetes mellitus is a disorder in which the pancreas cannot createsufficient insulin. In a diabetic state, a person suffering from highblood sugar may experience an array of physiological side effectsassociated with the deterioration of small blood vessels. These sideeffects may include, for example, kidney failure, skin ulcers, bleedinginto the vitreous of the eye, and the like. A hypoglycemic reaction,such as a low blood sugar event, may be induced by an inadvertentoverdose of insulin, or after a normal dose of insulin orglucose-lowering agent. In a severe hypoglycemic reaction, there may bea high risk for headache, seizure, loss of consciousness, and coma.

A diabetic person may carry a self-monitoring blood glucose (SMBG)monitor which typically requires the user to prick his or her finger tomeasure his or her glucose levels. Given the inconvenience associatedwith traditional finger pricking methods, it is unlikely that a diabeticwill take a timely SMBG measurement and, consequently, may be unawarewhether his or her blood glucose value is indicative of a dangeroussituation.

Consequently, a variety of non-invasive, transdermal (e.g.,transcutaneous) and/or implantable electrochemical sensors have been andare being developed for detecting and/or quantifying glucose values fromsuch sensor measurements having accuracy corresponding to direct bloodglucose measurements. These devices generally transmit raw or minimallyprocessed data for subsequent analysis at a remote device. The remotedevice may have a display that presents information to a user hostingthe sensor. In some systems, a patient may check his or her glucoselevel on a hand held computing device. There are challenges topresenting this information discreetly and reliably. Moreover, there arechallenges to efficiently analyzing this information to provide reportsand insights to the diabetic user and his/her caregiver network formanaging the diabetic condition.

SUMMARY

Methods and apparatus, including computer program products, are providedfor sharing data and/or reports. In some example embodiments, there isprovided a method, which includes sending a message to a server, whereinthe message includes a request for a share code to enable another userto access, via a first computer, analyte data obtained from ahost-patient associated with a receiver and/or an analyte report for thehost-patient associated with the receiver; receiving, in response to thesending, the share code generated by the server, wherein the share codecomprises a checksum portion, a password portion, and an identifierportion indicative of the host-patient; generating a user interface viewincluding the share code; and displaying the user interface viewincluding the share code, wherein the share code enables the other userto access, via the first computer, the analyte data and/or the analytereport.

In some example embodiments, one of more variations may be made as wellas described in the detailed description below and/or as described inthe following features. The first computer including an application mayprovide the share code to the server. The application may comprise adownloaded application and/or a browser that accesses, via a wiredconnection and/or wireless connection, the server. The providing of theshare code may comprise at least one of: entering the share code at awebpage generated by the server; or sending to the server anothermessage including the share code. The server may check the share code todetermine whether an account associated with the host-patient indicatesthat the share code authorizes report generation at the first computer.The checking may further include checking the checksum portion of theshare code, checking the password portion of the share code, when thechecksum is valid, and verifying the identity portion of the share codeby checking whether the identity portion maps to the account associatedwith the host-patient, when the checksum and password portion are valid.The verifying may further include determining whether a lifetime for theshare code has expired. The lifetime may be selected by the host-patientand/or configured as a default time. The server may generate the analytereport, when the checking determines that report generation isauthorized for presentation at the first computer. The sending of therequest for the share code may be triggered, when the host-patientaccesses a share code request icon presented on webpage generated by theserver. The third sharing mode may include enabling the other user toaccess, via the first computer, the analyte data obtained fromhost-patient associated with the receiver and/or the analyte report forthe host-patient associated with the receiver.

When in a first sharing mode, analyte data obtained from thehost-patient may be uploaded to the server, wherein the analyte data mayinclude continuous glucose sensor data and patient identifyinginformation identifying host-patient. The uploading to the server mayinclude transmitting the analyte data via at least one of a wired link,a cellular data link, a wireless local area network link, and/or aBluetooth link. The uploading may be performed by the receiverconfigured to wirelessly receive at least the continuous glucose sensordata from a continuous glucose sensor affixed to the host-patient. Theuploading may be via a remote computer. The uploading may be triggeredwhen the receiver couples via at a wired connection and/or a wirelessconnection to the remote computer that is authenticated by the server.The authentication may include a login to an account associated with thehost-patient. The analyte report may be generated for presentation atthe remote computer, wherein the analyte report may include the analytedata and patient identifying information identifying the host-patient.

The analyte data obtained from the host-patient may be uploaded to theserver, when in a second sharing mode, wherein the analyte data includescontinuous glucose sensor data and excludes patient identifyinginformation identifying the host-patient. The receiver may exclude thepatient identifying information by at least one of removing, masking, orencrypting the patient identifying information. The uploading mayinclude transmitting, by the receiver, the analyte data via at least oneof a wired link, a cellular data link, a wireless local area networklink, and/or a Bluetooth link. The receiver may wirelessly receive theanalyte data from a continuous glucose sensor affixed to thehost-patient. The uploading may be via the first computer comprising atransient computer, wherein the transient computer is not logged into anaccount associated with host-patient. The uploading may be triggered byat least one of: coupling the receiver via at a wired connection and/orwireless connection to the transient computer; and receiving anindication of a selection of an icon on a webpage, wherein the iconrepresents the second sharing mode, wherein the second sharing modeenables another user to access the analyte data obtained from thehost-patient associated with the receiver and/or the analyte report forthe host-patient associated with the receiver, wherein the secondsharing mode inhibits sharing of the patient identifying informationidentifying the host-patient. When in the second sharing mode, theuploading may be triggered by a second sharing mode upload message sentfrom the server to the transient computer and/or the receiver. Theanalyte report may be generated for presentation at the transientcomputer, when the second sharing mode upload message is received.

In some example embodiments, there may be provided a multimode server.The server may provide a method including generating, by a server, afirst report including analyte data obtained from a host-patientassociated with a receiver and excluding patient identifying informationidentifying host-patient, when in a first sharing mode; generating, by aserver, a second report including the analyte data obtained from thehost-patient associated with the receiver and including patientidentifying information identifying the host-patient, when in a secondsharing mode; and generating, by a server during a specified lifetime, athird report including the analyte data obtained from the host-patientassociated with the receiver, when in a third sharing mode.

In some example embodiments, one of more variations may be made as wellas described in the detailed description below and/or as described inthe following features. The first sharing mode may further includetriggering a data upload to the server to include the analyte data andexclude the patient identifying information identifying thehost-patient. The first sharing mode may be triggered when the receiverproviding the data is not registered with the server. The first sharingmode may be triggered when the receiver providing the data is not loggedin and/or authenticated by the server. The second sharing mode mayinclude triggering a data upload to the server to include the analytedata and include the patient identifying information identifying thehost-patient. The second sharing mode may be triggered when the receiverproviding the data is registered with the server. The second sharingmode may be triggered when the receiver providing the data is not loggedin and/or authenticated by the server. The third sharing mode mayinclude providing a share code to enable sharing of the generated reportduring the specified lifetime. The share code may include a checksumportion, a password portion, and an identifier portion indicative of thehost-patient. The third sharing mode may be triggered when a share codeis received at the server. The method may include sending at least oneof the first report, the second report, and/or the third report. Theserver may send to the receiver an indication regarding whether toinclude or exclude the patient identifying information.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive. Further features and/or variations may beprovided in addition to those set forth herein. For example, theimplementations described herein may be directed to various combinationsand subcombinations of the disclosed features and/or combinations andsubcombinations of several further features disclosed below in thedetailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

The accompanying drawings, which are incorporated herein and constitutea part of this specification, show certain aspects of the subject matterdisclosed herein and, together with the description, help explain someof the principles associated with the subject matter disclosed herein.In the drawings,

FIG. 1 illustrates a continuous analyte sensor system, in accordancewith some example embodiments;

FIG. 2 illustrates a functional block diagram of a mobile device usedwith the continuous analyte sensor system, in accordance with someexample embodiments;

FIG. 3 illustrates an example of a process for providing multiplesharing, in accordance with some example embodiments;

FIG. 4A depicts an example process for generating a share code, inaccordance with some example embodiments;

FIG. 4B depicts an example of a share code, in accordance with someexample embodiments;

FIGS. 5 and 6 depict examples of reports generated, in accordance withsome example embodiments;

FIG. 7 depicts an example user interface view at which a share code andoption can be selected and requested, in accordance with some exampleembodiments; and

FIG. 8 depicts an example user interface view presenting a share code,in accordance with some example embodiments.

Like labels are used to refer to same or similar items in the drawings.

DETAILED DESCRIPTION

When a patient (“host”) is monitored by a continuous glucose monitoringsystem, the patient may decide to generate reports in real-time as thedata is generated by the CGM sensor, or upload the data to a server,such as a secure server, to enable dynamic report generation usinghistorical CGM data as well as other types of data. These reports mayprovide insights with respect to glucose trends, such as patternsrelated to low glucose levels, patterns related to high glucose levels,percentage of time within a desired glucose range and/or at a desiredglucose level (or, conversely, out of the desired glucose range or notat the desired glucose level, e.g., a percentage of time in a highglucose range or level that is above a certain threshold and/or apercentage of time in a low glucose range or level that is below acertain threshold), and other statistics and information as well. Thesereports may also take into account other types of data, such as apatient's activity level (for example, calories burned, heartrate, timeawake, time sleeping, and the like as measured by a wearable device),diet (for example, caloric intake), treatment activity (for example,medicament dosing, type and/or quantity of medicament, etc.), and thelike. As such, these reports may have a meaningful impact with respectto the management of the patient's glucose level. Given the value ofthis report information, a patient may want to share this informationwith others, such as caregivers including family, healthcare providersincluding doctors, nurses, and others. However, the patient should nothave to compromise his or her privacy in order to share thisinformation.

In some example embodiments, a CGM receiver may have multiple,configurable sharing modes.

In some example embodiments, the CGM receiver may have at least a firstsharing mode, a second sharing mode, and a third sharing mode.

In a first sharing mode, the CGM receiver may couple to a remotecomputer. This remote computer may include an application, such as a CGMapplication. The CGM application may comprise an application downloadedfrom a server, such as a secure server or website for example.Alternatively or additionally, the CGM application may comprise abrowser that provides a web interface to a server or secure server.Moreover, the remote computer may be registered with, or logged in to,the secure server, so that the secure server can detect the remotecomputer's provenance (for example, trust level) as being affiliatedwith the patient (for example, via a login, an IP address, a MACaddress, and/or the like). Although the previous example describes theCGM application as being downloaded from a server, this application maybe provided to the remote computer in other ways as well.

When the patient logs in to the secure server via the remote computerincluding the CGM application, the remote computer may upload, from theCGM receiver, CGM data and forward the uploaded data from the CGMreceiver to the secure server, where the patient's CGM data may bestored and used to generate reports.

In some example embodiments, the remote computer including the CGMapplication may, while logged in to the secure server for example,receive the host patient's CGM data, alerts, and the like and receivethe host patient's CGM report(s) generated by the secure server. In thisway, the patient can view their CGM reports on the remote computer. Insome example embodiments, the remote computer is allowed to receive theCGM data, alerts, and reports so long as the CGM receiver is coupled tothe remote computer via a wired or wireless link.

Although the first sharing mode is useful, this first sharing moderepresents a trusted mode as the CGM reports are presented withinformation identifying the patient, so the first sharing mode may notalways be appropriate for sharing with others. For example, the remotecomputer may be a home computer, so sharing patient identifyinginformation on this computer may not represent a security or privacyrisk. In contrast, if the computer is a public or semi-public computerused by a variety of people, such as a shared computer at a clinic ordoctor's office for example, the first sharing mode may not suitablewith respect to security and privacy given the so-called “transient”nature of the computer. As such, the CGM receiver may operate in thesecond or third sharing modes to provide some level of privacy whensharing CGM data including reports.

In the second sharing mode, the CGM receiver may couple to a transientcomputer. For example, a patient may visit a clinic or a hospital, andthen couple, via a wired or wireless link, to the transient computer.This computer may include a CGM application that can provide access,such as browse, to the secure server or a web page affiliated with thesecure server. When in the second sharing mode, the CGM receiver mayupload data to the secure server via the transient computer. However,while in the second mode, the CGM receiver may perform this upload in ananonymous mode. For example, the CGM receiver may upload the patient'sCGM data but patient identifying information may not be uploaded via thetransient computer to the secure server. For example, the CGM receivermay upload data to the server but remove the patient identifyinginformation. Alternatively or additionally, the CGM receiver may uploaddata to the secure server but anonymize (for example, scramble or maskwith all “1” for example) any patient identifying information.Alternatively or additionally, the CGM receiver may upload data to theserver but encrypt the patient identifying information, such as thepatient's name, the CGM receiver serial number, and/or other patientidentifying information.

In some example embodiments, a CGM receiver may, via a wireless or wiredlink, couple to a computer, such as a transient computer, to perform adata upload to a server, such as a secure server. When that is the case,the transient computer may access (for example, browse to) a web pageassociated with the secure server. At this web page, the user may selectan anonymous upload mode icon on the web page. This selection maytrigger instructions to the CGM receiver and/or transient computer toupload CGM data and/or other data from the CGM receiver without patientidentifying information. Once the data is uploaded to the secure server,the secure server may generate reports, which can be presented at thecomputer, for example. But the reports may be generated and presented atthe transient computer without patient identifying information.

Although the previous example describes a user of the CGM receiverselecting via a web page the second, anonymous upload mode, this secondmode may be triggered in other ways as well. For example, the secureserver may assess the provenance of the uploading, transient computer,for example, whether the uploading, transient computer is on a trustedcomputer list for the CGM receiver, whether the access is logged in to apatient's account, whether the IP or MAC address is associated with thepatient's account, and/or the like. Based on this assessment, the secureserver may send an anonymous upload mode message to the transientcomputer and/or CGM receiver to trigger the anonymous upload mode.Alternatively or additionally, the CGM receiver may detect theprovenance of the transient computer, and configure the anonymous uploadmode accordingly.

To view reports in the second sharing mode, the transient computerincluding the CGM application may present CGM reports generated by thesecure server. However, the CGM reports generated for the second sharingmode may be anonymized, so that the reports do not show patientidentifying information, such as the patient's name, the CGM receiverserial number, and other patient identifying information. Moreover, thetransient computer including the CGM application may be configured tonot store or email reports, so that after the session the CGM reportspresented by transient computer including the CGM application may not bepersisted to permanent storage. In this way, the patient can view theirCGM reports with a caregiver in a relatively secure manner, while theCGM receiver is coupled to the transient computer and in the secondsharing mode.

In the third sharing mode, the patient may provide a share code toanother user, such as a caregiver and the like. For example, the patientmay access the secure server via the CGM receiver or a computer, such asa remote computer. Next, the patient may select, via a user interfaceview presented at the CGM receiver or computer, share code generation.This selection may trigger a request for the share code to be generated.This request may also specify a time over which the share code is valid.The secure server may then generate a share code and associate the sharecode with the requesting patient's account. Next, the secure server mayprovide (for example, transmit, send, and the like) the share code tothe CGM receiver or remote computer. The patient may then provide theshare code to another user, such as a caregiver. To provide the sharecode, the patient may email, text, or provide the code in any other way.

With the share code, the caregiver may access, via for example atransient computer, the secure server and request CGM reports for thepatients. Moreover, the share code may be valid for a time specified bythe patient, as noted. When this is the case, the caregiver may accessthe secure server to obtain the patient's CGM reports for the durationspecified by the selected or configured time. While in the third sharingmode, the transient computer including the CGM application may providefor presentation CGM reports generated by the secure server. However,the secure server may generate CGM reports for a limited time period,which can be selected by the user patient or provided as a default timeby the secure server. While in this third, share code mode, the secureserver may generate CGM reports including patient identifyinginformation. When this is the case, the CGM receiver uploads CGM data tothe secure server including patient identifying information. While inthe share code mode, the secure server may be configured to generate CGMreports without patient identifying information as well so that thereports lack patient identifying information, such as a patient's name,the CGM receiver serial number, and/or other patient identifyinginformation. When this is the case, the CGM receiver may upload CGM datato the secure server without patient identifying information.

Moreover, the transient computer including the CGM application may beconfigured to not store or email reports, so that after the session theCGM reports presented are not persisted to storage. In this way, thethird sharing mode allows a patient to provide CGM reports to anotheruser in a relatively secure manner (for example, anonymized and for alimited time period).

Before providing additional details for the three modes, the followingprovides an example system description in which the multimode system maybe implemented.

FIG. 1 is a schematic view of a continuous analyte sensor system 100coupled to a host, such as a patient, and communicating with a number ofexample devices 110-113, in accordance with some example embodiments.

A transcutaneous analyte sensor system 100 includes an on-skin sensorassembly 101 that is fastened to the skin of a host via a disposableinserter or applicator (not shown). The system 100 includes atranscutaneous analyte sensor 102 and a transmitter/sensor electronicsunit 104 for wirelessly transmitting analyte information to a receiveror receivers, such as devices 110-113. In some alternative embodiments,the sensor may be non-invasive.

During use, a sensing portion of the sensor 102 is under the host'sskin, and a contact portion of the sensor 102 is electrically connectedto the electronics unit 104. The electronics unit 104 engages a housingof the on-skin assembly 101 (not shown), and the sensor 102 extendsthrough the housing. The housing, which maintains the assembly 101 onthe skin and provides for electrical connection of the sensor 102 tosensor electronics provided in the electronics unit 104, is attached toan adhesive patch (not shown) fastened to the skin of the host.

The on-skin sensor assembly 101 may be attached to the host with anapplicator (not shown) adapted to provide convenient and secureapplication. Such an applicator may also be used for attaching theelectronics unit 104 to a housing, inserting the sensor 102 through thehost's skin, and/or connecting the sensor 102 to the electronics unit104. Once the electronics unit 104 is engaged with the housing and thesensor 102 has been inserted and is connected to the electronics unit104, the applicator detaches from the sensor assembly.

The continuous analyte sensor system 100 includes any sensorconfiguration that provides an output signal indicative of aconcentration of an analyte. The output signal, which may be in the formof, for example, sensor data, such as a raw data stream, filtered data,smoothed data, and/or otherwise transformed sensor data, is sent to areceiver, which is described in more detail below. In variousembodiments, the analyte sensor system 100 includes a transcutaneousglucose sensor, a subcutaneous glucose sensor, a continuous refillablesubcutaneous glucose sensor, or a continuous intravascular glucosesensor, for example.

In some embodiments, the sensor 102 extends through a housing (notshown), which maintains the sensor on the skin and provides forelectrical connection of the sensor-to-sensor electronics, provided inthe electronics unit 104. In some embodiments, the sensor 102 is formedfrom a wire. For example, the sensor can include an elongated conductivebody, such as a bare elongated conductive core (e.g., a metal wire) oran elongated conductive core coated with one, two, three, four, five, ormore layers of material, each of which may or may not be conductive. Theelongated sensor may be long and thin, yet flexible and strong. Forexample, in some embodiments the smallest dimension of the elongatedconductive body is less than about 0.1 inches, 0.075 inches, 0.05inches, 0.025 inches, 0.01 inches, 0.004 inches, or 0.002 inches, albeitother dimensions of the conductive body can be used. A membrane systemmay be deposited over at least a portion of electroactive surfaces ofthe sensor 102 (including a working electrode and optionally a referenceelectrode) and provides protection of the exposed electrode surface fromthe biological environment, diffusion resistance (limitation) of theanalyte if needed, a catalyst for enabling an enzymatic reaction,limitation or blocking of interferents, and/or hydrophilicity at theelectrochemically reactive surfaces of the sensor interface.

The membrane system may include a plurality of domains, for example, anelectrode domain, an interference domain, an enzyme domain (for example,including glucose oxidase), and a resistance domain, and can include ahigh oxygen solubility domain, and/or a bioprotective domain. Themembrane system may be deposited on the exposed electroactive surfacesusing known thin film techniques (for example, spraying,electro-depositing, dipping, etc.). In some embodiments, one or moredomains are deposited by dipping the sensor into a solution and drawingout the sensor at a speed that provides the appropriate domainthickness. However, the membrane system can be disposed over (ordeposited on) the electroactive surfaces using any known method.

In the illustrated embodiment, the electronics unit 104 is releasablyattachable to the sensor 102, which together form the on-skin sensorassembly 101. The electronics unit 104 includes electronic circuitryassociated with measuring and processing the continuous analyte sensordata, and is configured to perform algorithms associated with processingand calibration of the sensor data. The electronics unit 104 may includehardware, firmware, and/or software that enable measurement of levels ofthe analyte via the analyte sensor 102, e.g., such as glucose levels inembodiments of the analyte sensor 102 as a glucose sensor. For example,the electronics unit 104 can include a potentiostat, a power source forproviding power to the sensor 102, other components useful for signalprocessing and data storage, and preferably a telemetry module for one-or two-way data communication between the electronics unit 104 and oneor more receivers, repeaters, and/or display devices, such as thedevices 110-113. Sensor electronics within the electronics unit 104 canbe affixed to a printed circuit board (PCB), etc., and can take avariety of forms. For example, the electronics can take the form of anintegrated circuit (IC), such as an application-specific integratedcircuit (ASIC), a microcontroller, and/or a processor. The electronicsunit 104 may include sensor electronics that are configured to processsensor information, such as storing data, analyzing data streams,calibrating analyte sensor data, estimating analyte values, comparingestimated analyte values with time corresponding measured analytevalues, analyzing a variation of estimated analyte values, such asestimated glucose values (EGVs), and/or the like.

The devices 110-113 may operate as repeaters, receivers, and/or displaydevices (also referred to herein more generally as “receivers” or “CGMreceivers”). In the example of FIG. 1, device 110 comprises a key fobrepeater 110, device 111 comprises a dedicated medical device receiver111, device 112 comprises a smart phone 112 including an application135D (e.g., such as a CGM application) to provide the receiver disclosedherein, and device 113 comprises a portable or tablet computer 113including an application 135C (e.g., such as a CGM application) toprovide the receiver disclosed herein; although other types of devicescapable of receiving, repeating, and/or displaying the analyte sensordata provided by electronics unit 104 may be used as well. Devices110-113 may be operatively linked (via wireless link(s)) to theelectronics unit 104.

The repeaters, receivers, and/or display devices 110-113 may receivedata from electronics unit 104, which is also referred to as thetransmitter and/or sensor electronics body herein. For example, thesensor data can be transmitted from the sensor electronics unit 104 toone or more of the key fob repeater 110, the medical device receiver111, the smart phone 112, the portable or tablet computer 113, and thelike.

In some implementations, the repeaters, receivers and/or display devicesmay also transmit data to the electronics unit 104. In someimplementations, the repeaters, receivers, and/or display devices maytransmit data to one another or to other servers and/or computers. Forexample, medical device receiver 111 may receive analyte data such asCGM data from transmitter 104. Medical device receiver 111 may displaythe CGM data as well as related alerts and the like. Medical devicereceiver 111 may also provide the CGM data to other devices, suchdevices 110, 112, 113, as well as one or more other servers, such assecure server 130, via for example network 120 and/or directly throughwired or wireless communications. Similarly, for example, smart phone112 may receive the CGM data directly from the transmitter 104. Smartphone 112 can display the CGM data as well as related alerts and thelike, as well as may also provide the CGM data to other devices, such asthe devices 110, 113, or wearable devices like a smart watch or smartglasses connected to the smart phone 112, as well as one or more otherservers, such as secure server 130, via for example network 120 and/ordirectly through wired or wireless communications.

Data output from an output module of the receiver can provide wiredand/or wireless, one- or two-way communication between the receiver andan external computing device. This external computing device can be anydevice that interfaces or communicates with the receiver. In someembodiments, the external computing device is a computer or server, andthe receiver is able to download current and/or historical data forretrospective analysis by a patient, caregiver, physician, and the likefor example. In some embodiments, the external computing device is amodem, and the receiver is able to send alerts, warnings, emergencymessages, etc., via telecommunication lines to another party, such as adoctor and/or a family member. In some embodiments, the externalcomputing device is an insulin pen or insulin pump, and the receiver isable to communicate therapy recommendations, such as an insulin amountand a time to the insulin pen or insulin pump. The external computingdevice can include other technology or medical devices, for examplepacemakers, implanted analyte sensor patches, other infusion devices,telemetry devices, etc. Moreover, in some example embodiments, a varietyof data, such as the therapy recommendations, and other deviceinformation, such as fitness monitors, pacemakers, etc., may be uploadedto the secure server in accordance with first, second, and/or thirdmodes disclosed herein. In addition, the reports generated in accordancewith first, second, and/or third sharing modes disclosed herein mayinclude a variety of data including therapy recommendations, otherdevice data, etc.

The receiver may communicate with other devices via any suitablecommunication protocol including radio frequency (RF), Bluetooth,Bluetooth Low Energy (BLE), universal serial bus (USB), any of thewireless local area network (WLAN) communication standards, includingthe IEEE 802.11, 802.15, 802.20, 802.22 and other 802 communicationprotocols, ZigBee, wireless (e.g., cellular) telecommunication, pagingnetwork communication, magnetic induction, satellite data communication,GPRS, 3G, 4G, 5G, LTE, ANT, and/or a proprietary communication protocol.

Remote computer 145A may be accessed by the host-patient or others (whenauthorized) to access CGM data and/or CGM reports, and the data andreports may be obtained from the devices 111-113 or secure server 130.For example, remote computer 145A may be utilized by the host-patient, aremote follower (such as a parent or the like assisting in the trackingof the host-patient's CGM data), or other user.

In some example embodiments, remote computer 145A may download from aserver, such as secure server 130, an application such as CGMapplication 135A for receiving, transmitting, and/or displaying CGM dataas well as other types of data. In some example embodiments, CGMapplication 135A may also present reports generated by the secureserver. Moreover, CGM application 135A may enable a CGM receiver toupload data to secure server 130. While continuous glucose monitoring(CGM) data is discussed in this and other examples in this disclosure,it is understood that other analyte data can be monitored and processedin accordance with the various embodiments of the present technology.

In some example embodiments, CGM application 135A may, alone or incombination with secure server 130, control whether to implement a firstsharing mode, second sharing mode, or third sharing mode. In someexample embodiments, a web page at the secure server may allow selectionof the first sharing mode, second sharing mode, and/or third sharingmode. For example, the CGM application may browse to the web page andselect a user interface element corresponding to one of modes. Theselection may trigger the CGM application (for example, an uploader atthe CGM application) to share data in accordance with the selected mode.

Transient computer 145B may be similar to remote computer 145A in somerespects but may be a computer that is not typically used by thehost-patient. For example, the transient computer 145B may be a sharedcomputer at a clinic, where the patient may be receiving care. In thisexample, the patient may want to share CGM data and/or other data withfor example a caregiver, such as a nurse or doctor. But the patient maywant to limit access to the CGM data and report data in order to enhanceprivacy, especially in this example where the transient computer is ashared, semi-public computer at clinic. While in the second sharing modeor third sharing mode, the patient's CGM data and CGM reports may beviewed via the CGM application 135B.

The secure server 130 may have at least one processor and at least onememory storage device, such as a database, that receives, stores, andprocesses data received from one or more of the key fob repeater 110,the medical device receiver 111, the smart phone 112, the portabletablet computer 113, and other devices. A remote device may couple tothe server 130 to access sensor data associated with a given hostcoupled to the sensor/transmitter. For example, a caregiver, a parent,and/or the like at a computer 145A or 145B may receive, from the secureserver or other device, sensor data, reports, associated alerts, and thelike to remotely follow a host-patient at receiver 112.

Server 130 may comprise one or more servers accessible via a network,such as the Internet and the like. The secure server 130 may be securein the sense that patient data may be secured in order to restrictaccess to a patient's private data, such as the patient's CGM data,patient identifiable data, therapy recommendations, other device data,and/or the like. The secure server 130 may include a database 138B forstoring analyte data for the host(s) and/or other host related data andfor mapping each host account to a share code including options; a sharecode generator 138A for generating share codes; a report generator 137for generating CGM reports for one or more patients; a transient accesscontroller 139 for controlling access via the sharing modes disclosedherein; and/or an application downloader 134 for providing a CGMapplication to example devices, such as computers 145A-B and devices110-113; and/or one or more web pages where a share mode selection maybe performed.

The display device, such as tablet 113, may generate a user interfaceview, via the CGM application 135C for example, for presentation at adisplay. This user interface view may include analyte values, such asCGM data, prompts or messages to convey information to the user, such asreference outlier values, requests for reference analyte values, therapyrecommendations, deviation of the measured analyte values from theestimated analyte values, CGM reports (for example, reports includingCGM-related information for the host-patient), prompts to guide the userthrough calibration or troubleshooting of the calibration, other devicedata (for example, fitness data, pacemaker data, infusion pump data,other sensor data, etc.) and/or the like. A device may download the CGMapplication disclosed herein from server 130, although the CGMapplication may be configured on the device in other ways as well (forexample, pre-configured during manufacture and the like).

FIG. 2 is a functional block diagram of an embodiment of a system 200for leveraging mobile device features in continuous analyte monitoring,such as continuous glucose monitoring, according to some exampleembodiments.

The system 200 may comprise a mobile device 202, which may be any typeof computing device capable of receiving one or more inputs andproducing an output. Examples of the mobile device 202 include a smartphone 112, a tablet 113 computing device, a laptop, and/or the like. Themobile device 202 may include at least one memory 204 and at least oneprocessor 206. The memory 204 may provide the processor 206 access todata and program information that is stored in the memory 204 atexecution time. Typically, the memory 204 may include random accessmemory (RAM) circuits, read-only memory (ROM), flash memory, etc., or acombination thereof. The processor 206 may be, or may include, one ormore programmable general-purpose or special-purpose microprocessors206, digital signal processors 206 (DSPs), programmable controllers,application specific integrated circuits (ASICs), programmable logicdevices (PLDs), etc., or a combination of such hardware-based devices.

In accordance with some embodiments, the processor 206 may execute acontinuous glucose monitoring (CGM) application 208 out of the memory204.

In accordance with some embodiments, CGM application 208 may beconfigured to control, alone or in combination, the multiple sharingmodes disclosed herein. Moreover, the CGM application may be configuredto receive data from the transmitter, display CGM data, alerts,messages, and reports (for example, which may be generated by the secureserver or generated at the CGM application itself), transmit (or upload)data to other devices, such as server 130, computers 145A-B, and devices110-113, and receive data from other devices, such as server 130,computers 145A-B, and devices 110-113. The CGM application may, asnoted, comprise a browser configured to access via network 120 (forexample, the Internet) the secure server. The CGM application may alsobe configured to analyze CGM data provided by a transmitter as well asother data provided by other devices. As used herein, the phrase or termassociated with the CGM application should be construed broadly toinclude not just the application itself, but also integration withsensor 102, other diabetes management devices, including insulindelivery therapies such as insulin pumps, insulin pens, or other drugsuseful for the treatment of diabetes. In other words, the CGMapplication may perform other functions besides monitoring glucose(which may include interstitial and/or blood glucose measurements). Itcould, for example, determine that a user's glucose level is high, andthen transmit a signal to the user's insulin pump to administer aquantity of insulin to bring the user's glucose level down.

A software and/or firmware component of the CGM application 208 may bestored in storage 210 available to the mobile device 202, and loadedinto the memory 204 at execution time. The storage 210 may be anynon-transitory computer readable media including, but not limited to, ahard disk, EEPROM (electrically erasable programmable read only memory),a memory stick, or any other storage device type. The memory 204 maycontain one or more data structures 212 that the CGM application 208accesses during execution. For example, the CGM application 208 mayreceive an input and store the input as an input parameter in a datastructure 212 in the memory 204 for later processing.

In some embodiments, the CGM application 208 may be embodied asdownloadable software that a user may download from a remote server,such as server 130, through a wired or wireless connection. For example,the user may access the server using an application already installed onthe user's mobile device. The user may then download and install the CGMapplication 208 with the aid of the application. The user may thenconfigure the CGM application 208. For example, the configuration mayinclude setting the user's personal preferences and/or settings, such ascontacts, events, modes, profiles, and/or the like. The configurationmay be done manually, such as by selecting various options from menus,or automatically. In automatic configuration, the CGM application 208reads the user's preferences and/or settings that are stored on themobile device 202. For example, in some implementations, the CGMapplication 208 would first discover what other applications areinstalled on the mobile device, and then access those applications' datastored in the mobile device's storage and/or remote storage accessibleby the mobile device 202 to initially populate the CGM application 208during set up.

In some implementations of the system 200, the CGM application 208operating on the mobile device 202 receives at least one input 214 fromthe CGM transmitter or other device, such as devices 110-113. Forexample, the input can include a current estimated glucose value (EGV)for the patient or user input by and/or about the patient. In someimplementations, the CGM application 208 receives input from anauxiliary interface 216. The auxiliary interface 216 may be any ofhardware, software, firmware, or a combination of any of these, and maycomprise anything that may be combined with EGV data and processed toproduce an output that can provide the user with information that canhelp him or her make more informed decisions about how to manage his orher glucose. In some embodiments, for example, the auxiliary interface216 may be a sensor, which may be internal or external to the mobiledevice 202, or may be another application executed by the mobile device202.

In some implementations of the system 200, the CGM application 208operating on the mobile device 202 processes the inputs in conjunctionwith the processor 206 to produce one or more outputs 218, 220. Forexample, the output 218 may be to a device or receiver external to themobile device 202 (shown as CGM Module Output 1, 218, in FIG. 2), or toa device internal to the mobile device 202 (shown CGM Module Output 2,220), such as to a display 222 or storage 210.

FIG. 3 illustrates a process 300 flow illustrating the multiple modes ofoperation for system 100, in accordance with some example embodiments.

At 302, a CGM application may be downloaded to a device, in accordancewith some example embodiments. For example, server 130 may download oneor more CGM applications 135A-D to one or more devices, such as a remotecomputer 145A, transient computer 145B, other devices 110-113, and/orthe like. The CGM application may be downloaded on demand when requestedfor example, although the CGM application may be installed and/orconfigured at other times as well (for example, during the manufactureof the device). Moreover, the downloaded CGM application may be updatedby the secure server 130 from time to time to provide software updatesand the like.

To illustrate further, smart phone 112 may, in addition to providingcellular and internet function, may download CGM application 135D. Thissmart phone 112 may couple to a computer, such as a remote computer 145A(although other types of computers may be coupled to as well). Thecomputer 145A may be a computer that is associated with the hostpatient's device. For example, the smart phone 112 (which in thisexample provides a CGM receiver) including CGM application 135D may becoupled via a wired link for example, such as a USB link, to the remotecomputer 145A, which may also including a corresponding CGM application135A (although the link may be wireless as well). The CGM application135A may be registered to or associated with the host patient of the CGMreceiver. For example, the remote computer 145A may be the hostpatient's home computer, and, as such, there may be a higher degree oftrust (or known provenance, for example) when compared to othercomputers. Alternatively or additionally, remote computer 145A may beassociated with a caretaker (for example, a parent and the like) of thehost patient, and, as such, there may be a higher degree of trust (orknown provenance, for example) when compared to other computers. In bothof these examples, the computers are not transient computers, but ratherthe computers that are somewhat private computers used primarily by thehost patient or a remote follower (for example, a person authorized tofollow the host patient having a computer of relatively knownprovenance). Moreover, the remote computer 145A may from time to timeaccess a web page at the secure server, and, as such, the secure servermay further detect the provenance of the remote computer (for example,via login(s), IP addresses, MAC addresses, and/or the like). Bycontrast, a transient computer may be characterized as a computer thatis publically accessible by users other than the host patient or remotefollower. For example, a transient computer 145B may be a sharedcomputer at a clinic where a variety of patients and caregivers that mayseek access to CGM data and corresponding CGM reports. As such, thetransient computer 145B may not be trusted and, as such, the transientcomputer may not be trusted or the provenance of the transient computer(for example, via prior login(s) and/or the like) may not be detected orknown.

If the computer (to which the CGM couples) is not a transient computer(no at 305 to arrive at block 307), the sharing mode may be configuredto operate in a first sharing mode. In the first sharing mode, the CGMreceiver with CGM application 135C-D, for example, may couple to theremote computer 145A to gain access to the remote computer 145A and/orthe secure server 130. The remote computer 145A may be registered with,or logged in to, the secure server 130, so that the secure serverrecognizes the remote computer as being affiliated with the patient andthe patient's device (for example, via login to the user's account, anIP address, a MAC address, login credentials, and the like). After alogin for example, remote computer 145A may upload CGM data from the CGMreceiver to the secure server to enable storage and report generation.Moreover, the remote computer and/or CGM receiver may receive CGMreports and other data generated by the secure server. While in thefirst sharing mode, the CGM data, reports, and the like may includepatient identifying information since there is a certain degree of trustwith respect to the remote computer 145A. The first sharing mode may beselected at a web page presented at the remote computer 145A or the CGMreceiver (for example, at CGM application 135D on smart phone 112).Alternatively or additionally, the first sharing mode may be implementedautomatically, without user selection. For example, the secure server130 and/or CGM application 135D on the smart phone 112 may detect thatthe user of smart phone 112 and CGM application 135D has logged in tothe host patient's account, and that data can be uploaded and/or reportspresented in accordance with the first mode.

If the computer (to which the CGM receiver couples to) is a transientcomputer, the host patient may be asked to select whether the sharingmode should be the second sharing mode (labeled “anonymous uploadmode”), in accordance with some example embodiments (yes at 305 and310). For example, the user may be presented with a user interface viewindicating whether the second sharing mode should be implemented. Whenthis is the case, the host patient may select the second sharing mode toenable the anonymous upload and sharing in accordance with the secondsharing mode (yes at 310 to arrive at block 315).

Although the previous example refers to the selection of the secondsharing mode by a user at a user interface, the second mode may beselected in other ways. For example, the second mode may be triggered bya message from the secure server. Alternatively or additionally, thesecond sharing mode may be a default mode configured during theprovisioning of the CGM receiver, for example. Alternatively oradditionally, the second sharing mode may be selected programmaticallybased on a scan of the computer to which the CGM receiver is coupled.For example, if a scan reveals that the computer is not on a trustedlist of computers or the provenance of the computer is unknown, the CGMreceiver and/or secure server may programmatically select the secondsharing mode. For example, the secure server 130 and/or CGM receiver(for example, CGM application 135D on smart phone 112) may detectwhether the sharing mode should be a second sharing mode. Specifically,the user of the CGM application 135D of smart phone 112 may not belogged in to the secure server 130, when the smart phone 112 couples tothe transient computer 145B for an upload. Alternatively oradditionally, the secure server 130 may not detect the provenance (andthus trust level) of the transient computer 145B, and thus trigger thesecond sharing mode. Alternatively or additionally, the secure servermay receive a request, such as an email or a web page request, to accessthe patient's data including CGM data. When this is the case, the secureserver may send a message to the CGM receiver (for example, smart phone112 including CGM application 135D) indicating to the user to selectwhether the second mode should be selected for use.

At 315, the CGM receiver may upload data to the secure server via thetransient computer, but in the second sharing mode, the CGM receiver mayperform this upload in an anonymous mode. For example, the CGM receiver(for example, smart phone 112 configured with CGM application 135D) mayupload the patient's CGM data not provide the patient identifyinginformation as noted above. To view reports in the second sharing mode,the transient computer 145B including the CGM application 135B mayprovide for presentation CGM reports generated by the secure server 130.While in the second sharing mode, the CGM reports generated for thesecond sharing mode may be anonymized so that the reports do not show,as noted, patient identifying information, such as the patient's name,the CGM receiver serial number, and/or other patient identifyinginformation. In some implementations, the transient computer includingthe CGM application may be configured to not store or send reports(e.g., via email). In this way, the second sharing mode provides somesecurity when a host patient seeks to share CGM data from a CGM receiveror CGM reports generated by the secure server with another, such as acaregiver, using a transient computer. For example, the upload of theCGM data from the CGM receiver (for example, smart phone 112 configuredwith CGM application 135D) via transient computer 145B to the secureserver may be secure, e.g., because the CGM data (as well as any otheruploaded data) may be anonymized and thus does not include patientidentifying information as noted above. In addition, any reportsgenerated by the secure server 130 and presented at the transientcomputer 145B are secure, e.g., as the reports do not include thepatient identifying information.

If the second sharing mode is not selected at 310 (no at 310), the hostpatient may select the third sharing mode (labeled “share code mode”),in accordance with some example embodiments. For example, the user ofthe CGM receiver (for example, smart phone 112 configured with CGMapplication 135D) may access a web page of the secure server 130. Thisweb page may include an icon, which when selected triggers the third,sharing mode (yes at 320 to arrive at block 325).

Although the previous example refers to the selection of the thirdsharing mode by a user at a user interface, the third mode may beselected in other ways. For example, the third sharing mode may betriggered by a message from the secure server. For example, the secureserver may receive a request (for example, an email, SMS message, or webpage request or indication) to access the patient's data including CGMdata. When this is the case, the secure server may send a message to theCGM receiver (for example, smart phone 112 including CGM application135D) indicating to the user to select whether the third mode should beselected for use. Alternatively or additionally, the secure server 130may not recognize the provenance of a computer requesting access to theuser's data, and, as such, send a message to smart phone 112 includingCGM application 135D indicating (or requesting) the third sharing mode.Alternatively or additionally, the third sharing mode may be a defaultmode configured at the CGM receiver, whenever the CGM receiver does notrecognize the provenance of the computer to which it couples.

At 325, the host patient may receive a share code, in accordance withsome example embodiments. For example, the share code may be generatedby the secure server and provided to a computer or the CGM receiver.When the patient has the share code, the patient may provide a sharecode to another user, such as a caregiver and the like. With the sharecode, the other user may access, via for example a transient computer,the secure server and request CGM reports for the patients. Moreover,the share code may be valid for a time specified by the patient, soafter the expiration of the share code, the transient computer will notbe allowed to receive, for that user/patient, CGM reports from thesecure server. As noted above, the CGM reports may be presented withpatient identifying information, although the CGM reports may bepresented without patient identifying information, such as the patient'sname, the CGM receiver serial number, and/or other patient identifyinginformation. In addition, the transient computer including the CGMapplication may be configured to not store or send reports. In this way,the third sharing mode provides some security when a host patient seeksto share CGM data from a CGM receiver or CGM reports generated by thesecure server with a caregiver using a transient computer.

FIG. 4A depicts an example process 400 for using a share code, inaccordance with some example embodiments. The description of FIG. 4Aalso refers to FIG. 1.

At 402, a user of receiver, such as device 113 for example, may login toserver 130 using for example a user name and password. Next, thereceiver associated with a host patient (currently logged in) maytransmit, at 410, a request to server 130 for a share code. For example,the device 113 may present a user interface view where a selection maybe performed indicating that a share code mode (referred to above as thethird sharing mode). This selection may trigger the transmission, at410, of the request. The request transmitted at 410 may be transmittedin a wireless and/or a wired manner via network 120 to secure server130.

In some example embodiments, the share code selection may include aselection of one or more options. For example, the option selection mayinclude a duration for the share code. The duration may define a timeduring which the share code is valid, and, as such, the secure servercan provide CGM data and/or reports so long as the duration has notexpired. The duration option may be selected as 5, minutes, 10 minutes,30 minutes, 1 hour, 2 hours, 3 hours, 24 hours, 2 days, 3 days, 1 week,1 month, 2 months, 3 months, or any other duration.

In some example embodiments, the options selection may be type ofreports. In some example embodiments, the options selection may includea selection of mode, such as report generation mode access, calibrationmode access, and the like.

For the patient that is registered to the device 113 and logged in, thesecure server may generate, at 412, a share code. For example, the sharecode may comprise a unique sequence of numbers, letters, characters,and/or symbols, and/or combinations thereof. In some implementations,the share code may comprise a unique sequence of 8 numbers, 9 numbers,10 numbers, 11 numbers, 12 numbers 13 numbers, and the like, althoughthe sequence may have other lengths as well. Although the previousexample refers to a sequence of numbers, the share code may comprise asequence of characters, symbols, numbers, or combination thereof of anylength.

FIG. 4B depicts an example share code, in accordance with some exampleembodiments. In the example of FIG. 4B, the share code includes achecksum portion comprising one or more bits 456, a password portioncomprising one or more bits 454, and/or an identity 452 comprising oneor more bits. This three-layer share code may enable easierauthentication by the secure server. For example, a quick check of thechecksum may result in a denial of access (a server response indicationaccess denied, for example). Although FIG. 4B depicts a certain formatfor the share code, the share code may take other forms as well.

The check sum may take a variety of forms. For example, the check summay comprise a parity bit, a hash function, a check digit algorithm, aDamm algorithm, or the like.

In some example embodiments, an incorrect checksum may not be counted asa failed attempt, which might trigger an account lockout, for example.If the checksum is in error, the request may be denied as noted.However, if the password portion is incorrect as well, the server maykeep track of the mistaken password portions. Moreover, if there are acertain quantity of fails attempts having an incorrect password portion,the secure server may lockout access to the server by the transientcomputer until some other verification is performed or a time out periodlapses.

Referring again to FIG. 4A, the secure server may associate, at 414, thegenerated shared code with the patient's account (or ticket associatedwith the patient's login/account). With that association, the options,such as share code duration, mode, and type, may be recorded.

At 420, the generated share code may be transmitted to receiver 113. Forexample, the share code may be carried by a message, such as an email,SMS message, and any other type of message. When the generated sharecode is received, the share code may be extracted by the CGM application135C, for example, and presented via a user interface at receiver 113.

At 425, the generated share code may be provided to another user at, forexample, transient computer 145B. For example, the user of receiver 113may send, via SMS, text, or by other mechanisms the generated share codeto another user.

At 430, the other user may, via transient computer 145B, access thesecure server via network 120. For example, the other user may accesstransient computer 145B/CGM application 135B, and then browse orotherwise access the secure server to provide the generated share code.To illustrate further, when the transient computer 145B/CGM application135B access secure server 130, transient computer 145B/CGM application135B may send a share code provided, via a user interface view, by theother user.

At 437, the secure server checks the share code. In some exampleembodiments, the share code includes a checksum, a password, and/or anidentifier. When that is the case, the secure server may first check thechecksum. If the password portion is incorrect, then the secure serverrejects the share code and the requested access. Moreover, repeatedpassword errors may count as failed attempts that can result in alockout, as noted above.

If the secure server determines that the password portion is correct,then the secure server queries a database for the identifier portion,which is mapped to the patient's account or ticket. If the databaseincludes the identifier portion, the identifier portion may be mapped tothe patient's account or ticket. This mapping may indicate whether theshare code is still valid. For example, the duration option may define atime over which the share code is valid. In some example embodiments,the database may set a timer based on the duration option. If the timerhas not expired, access can be enabled. If the timer has expired, accesswill be denied. In some example embodiment, if the timer expires, theserver's database may send and terminate access to the report generatorto inform the report generator to stop providing CGM data and/or reportsto the expired share code user at the transient computer.

Moreover, the mappings may include allowed modes and data types. Whenthis is the case, the secure server may assess the allowed modes andtypes to determine whether to grant access.

If the share code has not expired and the access is granted, the secureserver may allow report requests 440 to result in report generationbeing provided to the transient computer for presentation. If the sharecode has expired and the access is denied, the secure server will notallow reports to be provided and presented at the transient computer.

FIGS. 5-8 depict examples of reports that may be generated by secureserver 130 and presented at a device or computer while in the first,second, or third sharing modes.

FIG. 5 depicts an example of user interface view 500 of a reportgenerated by the secure server. In the example report of FIG. 5, theuser interface view 500 may be presented at a computer or other device.Moreover, the user interface view 500 may include an indication 520 thatthe report has been generated in the second sharing mode (or “anonymousupload session”). As can be seen by the report, there is no patientidentifying information shown, but rather time range for the report,estimated A1C, average glucose level, time in range, hypoglycemia risk,and other information.

FIG. 6 depicts an example of a user interface view 600 of a reportgenerated by the secure server. In the example report of FIG. 6, theuser interface view 600 includes an indication 610 that the report hasbeen generated in the third sharing mode (or “sharing code session”). Inthis example, the report is over a certain time range and includesestimated A1C, average glucose level, time in range, hypoglycemia risk,and other information.

FIG. 7 depicts an example of a user interface view 700 presented at adevice. The user interface view allows a request for the share code tobe generated when the generate share code icon 705 is selected, andallows the selection of a duration option defining a time over which theshare code is active (and thus enabling access to CGM data and/orreport). In the example, the duration options include 3 months 710, 6months 712, or 1 year 714. In other examples, the duration options caninclude 2 hours, 30 days, or 90 days, although other time periods may beused as well.

FIG. 8 depicts an example of a user interface view 800 presented at adevice. The user interface view presents a share code 810. In thisexample, a host patient may provide another user with a share code. Theother user may access, via an application such as a browser, the secureserver at “clarity.dexcom.com/clinic.” After accessing the secureserver, the share code 810 may be entered as described above at 435.

EXAMPLES

The following examples are illustrative of several embodiments andimplementations in accordance with the present technology. Other exampleembodiments and implementations of the present technology may bepresented prior to the following listed examples, or after the followinglisted examples.

In some embodiments in accordance with the present technology (example1), a method includes sending a message to a server, wherein the messageincludes a request for a share code to enable another user to access,via a first computer, analyte data obtained from a host-patientassociated with a receiver and/or an analyte report for the host-patientassociated with the receiver; receiving, in response to the sending, theshare code generated by the server, wherein the share code comprises achecksum portion, a password portion, and an identifier portionindicative of the host-patient; generating a user interface viewincluding the share code; and displaying the user interface viewincluding the share code, in which the share code enables the other userto access, via the first computer, the analyte data and/or the analytereport.

Example 2 includes the method of example 1, further including providing,by the first computer including an application, the share code to theserver.

Example 3 includes the method of example 2, in which the applicationcomprises a downloaded application and/or a browser that accesses, via awired connection and/or wireless connection, the server.

Example 4 includes the method of example 2, in which the providingcomprises at least one of entering the share code at a webpage generatedby the server; or sending to the server another message including theshare code.

Example 5 includes the method of example 2, further including checking,by the server, the share code to determine whether an account associatedwith the host-patient indicates that the share code authorizes reportgeneration at the first computer.

Example 6 includes the method of example 5, in which the checkingfurther comprises checking the checksum portion of the share code;checking the password portion of the share code, when the checksum isvalid; and verifying the identity portion of the share code by checkingwhether the identity portion maps to the account associated with thehost-patient, when the checksum and password portion are valid.

Example 7 includes the method of example 6, in which the verifyingfurther includes determining whether a lifetime for the share code hasexpired.

Example 8 includes the method of example 7, in which the lifetime isselected by the host-patient and/or configured as a default time.

Example 9 includes the method of example 5, further includinggenerating, by the server, the analyte report, when the checkingdetermines that report generation is authorized for presentation at thefirst computer.

Example 10 includes the method of example 1, further includingtriggering the sending of the request for the share code, when thehost-patient accesses a share code request icon presented on webpagegenerated by the server.

Example 11 includes the method of example 1, in which a third sharingmode comprises enabling the other user to access, via the firstcomputer, the analyte data obtained from host-patient associated withthe receiver and/or the analyte report for the host-patient associatedwith the receiver.

Example 12 includes the method of example 1, further includinguploading, when in a first sharing mode, to the server the analyte dataobtained from the host-patient, wherein the analyte data comprisescontinuous glucose sensor data and patient identifying informationidentifying host-patient.

Example 13 includes the method of example 12, in which the uploading tothe server further comprises transmitting the analyte data via at leastone of a wired link, a cellular data link, a wireless local area networklink, and/or a Bluetooth link.

Example 14 includes the method of example 12, in which the uploading isperformed by the receiver configured to wirelessly receive at least thecontinuous glucose sensor data from a continuous glucose sensor affixedto the host-patient.

Example 15 includes the method of example 12, in which the uploading isvia a remote computer.

Example 16 includes the method of example 12, in which the uploading istriggered when the receiver couples via at a wired connection and/or awireless connection to the remote computer that is authenticated by theserver.

Example 17 includes the method of example 16, in which theauthentication comprises a login to an account associated with thehost-patient.

Example 18 includes the method of example 12, further includinggenerating, for presentation at the remote computer, the analyte report,wherein the analyte report comprises the analyte data and patientidentifying information identifying the host-patient.

Example 19 includes the method of example 1, further includinguploading, when in a second sharing mode, to the server the analyte dataobtained from the host-patient, wherein the analyte data includescontinuous glucose sensor data and excludes patient identifyinginformation identifying the host-patient.

Example 20 includes the method of example 19, in which the receiverexcludes the patient identifying information by at least one ofremoving, masking, or encrypting the patient identifying information.

Example 21 includes the method of example 19, in which the uploadingfurther comprises transmitting, by the receiver, the analyte data via atleast one of a wired link, a cellular data link, a wireless local areanetwork link, and/or a Bluetooth link.

Example 22 includes the method of example 19, in which the receiverwirelessly receives the analyte data from a continuous glucose sensoraffixed to the host-patient.

Example 23 includes the method of example 19, in which the uploading isvia the first computer comprising a transient computer, wherein thetransient computer is not logged into an account associated withhost-patient.

Example 24 includes the method of example 23, in which the uploading istriggered by at least one of coupling the receiver via at a wiredconnection and/or wireless connection to the transient computer; andreceiving an indication of a selection of an icon on a webpage, in whichthe icon represents the second sharing mode, wherein the second sharingmode enables the other user to access the analyte data obtained from thehost-patient associated with the receiver and/or the analyte report forthe host-patient associated with the receiver, in which the secondsharing mode inhibits sharing of the patient identifying informationidentifying the host-patient.

Example 25 includes the method of example 19, further includingtriggering, when in the second sharing mode, the uploading by sending asecond sharing mode upload message from the server to the transientcomputer and/or the receiver.

Example 26 includes the method of example 25, further includinggenerating the analyte report for presentation at the transientcomputer, when the second sharing mode upload message is received.

In some embodiments in accordance with the present technology (example27), a system includes at least one processor; and at least one memoryincluding code which, when executed by the at least one processor,provides operations including sending a message to a server, wherein themessage includes a request for a share code to enable another user toaccess, via a first computer, analyte data obtained from a host-patientassociated with a receiver and/or an analyte report for the host-patientassociated with the receiver; receiving, in response to the sending, theshare code generated by the server, wherein the share code comprises achecksum portion, a password portion, and an identifier portionindicative of the host-patient; generating a user interface viewincluding the share code; and displaying the user interface viewincluding the share code, wherein the share code enables the other userto access, via the first computer, the analyte data and/or the analytereport.

Example 28 includes the system of example 27, further includingproviding, by the first computer including an application, the sharecode to the server.

Example 29 includes the system of example 28, in which the applicationcomprises a downloaded application and/or a browser that accesses, via awired connection and/or wireless connection, the server.

Example 30 includes the system of example 28, in which the providingcomprises at least one of entering the share code at a webpage generatedby the server; or sending to the server another message including theshare code.

Example 31 includes the system of example 28, further includingchecking, by the server, the share code to determine whether an accountassociated with the host-patient indicates that the share codeauthorizes report generation at the first computer.

Example 32 includes the system of example 31, in which the checkingfurther includes checking the checksum portion of the share code;checking the password portion of the share code, when the checksum isvalid; and verifying the identity portion of the share code by checkingwhether the identity portion maps to the account associated with thehost-patient, when the checksum and password portion are valid.

Example 33 includes the system of example 32, in which the verifyingfurther comprises determining whether a lifetime for the share code hasexpired.

Example 34 includes the system of example 33, in which the lifetime isselected by the host-patient and/or configured as a default time.

Example 35 includes the system of example 31, further includinggenerating, by the server, the analyte report, when the checkingdetermines that report generation is authorized for presentation at thefirst computer.

Example 36 includes the system of example 27, further includingtriggering the sending of the request for the share code, when thehost-patient accesses a share code request icon presented on webpagegenerated by the server.

Example 37 includes the system of example 27, in which a third sharingmode comprises enabling the other user to access, via the firstcomputer, the analyte data obtained from host-patient associated withthe receiver and/or the analyte report for the host-patient associatedwith the receiver.

Example 38 includes the system of example 27, further includinguploading, when in a first sharing mode, to the server the analyte dataobtained from the host-patient, wherein the analyte data comprisescontinuous glucose sensor data and patient identifying informationidentifying host-patient.

Example 39 includes the system of example 38, in which the uploading tothe server further comprises transmitting the analyte data via at leastone of a wired link, a cellular data link, a wireless local area networklink, and/or a Bluetooth link.

Example 40 includes the system of example 38, in which the uploading isperformed by the receiver configured to wirelessly receive at least thecontinuous glucose sensor data from a continuous glucose sensor affixedto the host-patient.

Example 41 includes the system of example 38, in which the uploading isvia a remote computer.

Example 42 includes the system of example 38, in which the uploading istriggered when the receiver couples via at a wired connection and/or awireless connection to the remote computer that is authenticated by theserver.

Example 43 includes the system of example 42, in which theauthentication comprises a login to an account associated with thehost-patient.

Example 44 includes the system of example 38, further includinggenerating, for presentation at the remote computer, the analyte report,in which the analyte report comprises the analyte data and patientidentifying information identifying the host-patient.

Example 45 includes the system of example 27, further includinguploading, when in a second sharing mode, to the server the analyte dataobtained from the host-patient, in which the analyte data includescontinuous glucose sensor data and excludes patient identifyinginformation identifying the host-patient.

Example 46 includes the system of example 45, in which the receiverexcludes the patient identifying information by at least one ofremoving, masking, or encrypting the patient identifying information.

Example 47 includes the system of example 45, in which the uploadingfurther comprises transmitting, by the receiver, the analyte data via atleast one of a wired link, a cellular data link, a wireless local areanetwork link, and/or a Bluetooth link.

Example 48 includes the system of example 45, in which the receiverwirelessly receives the analyte data from a continuous glucose sensoraffixed to the host-patient.

Example 49 includes the system of example 45, in which the uploading isvia the first computer comprising a transient computer, wherein thetransient computer is not logged into an account associated withhost-patient.

Example 50 includes the system of example 49, in which the uploading istriggered by at least one of coupling the receiver via at a wiredconnection and/or wireless connection to the transient computer; andreceiving an indication of a selection of an icon on a webpage, whereinthe icon represents the second sharing mode, wherein the second sharingmode enables the other user to access the analyte data obtained from thehost-patient associated with the receiver and/or the analyte report forthe host-patient associated with the receiver, wherein the secondsharing mode inhibits sharing of the patient identifying informationidentifying the host-patient.

Example 51 includes the system of example 45, further includingtriggering, when in the second sharing mode, the uploading by sending asecond sharing mode upload message from the server to the transientcomputer and/or the receiver.

Example 52 includes the system of example 45, further includinggenerating the analyte report for presentation at the transientcomputer, when the second sharing mode upload message is received.

In some embodiments in accordance with the present technology (example53), a non-transitory computer readable storage medium including programcode which when executed by at least one processor causes operationsincludes sending a message to a server, wherein the message includes arequest for a share code to enable another user to access, via a firstcomputer, analyte data obtained from a host-patient associated with areceiver and/or an analyte report for the host-patient associated withthe receiver; receiving, in response to the sending, the share codegenerated by the server, wherein the share code comprises a checksumportion, a password portion, and an identifier portion indicative of thehost-patient; generating a user interface view including the share code;and displaying the user interface view including the share code, whereinthe share code enables the other user to access, via the first computer,the analyte data and/or the analyte report.

In some embodiments in accordance with the present technology (example54), an apparatus includes means for sending a message to a server,wherein the message includes a request for a share code to enableanother user to access, via a first computer, analyte data obtained froma host-patient associated with a receiver and/or an analyte report forthe host-patient associated with the receiver; means for receiving, inresponse to the sending, the share code generated by the server, whereinthe share code comprises a checksum portion, a password portion, and anidentifier portion indicative of the host-patient; means for generatinga user interface view including the share code; and means for displayingthe user interface view including the share code, wherein the share codeenables the other user to access, via the first computer, the analytedata and/or the analyte report.

In some embodiments in accordance with the present technology (example55), a method includes generating, by a server, a first report includinganalyte data obtained from a host-patient associated with a receiver andexcluding patient identifying information identifying host-patient, whenin a first sharing mode; generating, by the server, a second reportincluding the analyte data obtained from the host-patient associatedwith the receiver and including patient identifying informationidentifying the host-patient, when in a second sharing mode; andgenerating, by the server during a specified lifetime, a third reportincluding the analyte data obtained from the host-patient associatedwith the receiver, when in a third sharing mode.

Example 56 includes the method of example 55, in which the first sharingmode includes triggering a data upload to the server to include theanalyte data and exclude the patient identifying information identifyingthe host-patient.

Example 57 includes the method of example 55, in which the first sharingmode is triggered when the receiver providing the data is not registeredwith the server.

Example 58 includes the method of example 55, in which the first sharingmode is triggered when the receiver providing the data is not logged inand/or authenticated by the server.

Example 59 includes the method of example 55, in which the secondsharing mode includes triggering a data upload to the server to includethe analyte data and include the patient identifying informationidentifying the host-patient.

Example 60 includes the method of example 55, in which the secondsharing mode is triggered when the receiver providing the data isregistered with the server.

Example 61 includes the method of example 55, in which the secondsharing mode is triggered when the receiver providing the data is notlogged in and/or authenticated by the server.

Example 62 includes the method of example 55, wherein the third sharingmode includes providing a share code to enable sharing of the generatedreport during the specified lifetime.

Example 63 includes the method of example 62, in which the share codecomprises a checksum portion, a password portion, and an identifierportion indicative of the host-patient

Example 64 includes the method of example 55, in which the third sharingmode is triggered when a share code is received at the server.

Example 65 includes the method of example 55, further including sendingat least one of the first report, the second report, and/or the thirdreport.

Example 66 includes the method of example 55, further including sendingto the receiver an indication regarding whether to include or excludethe patient identifying information.

In some embodiments in accordance with the present technology (example67), a system includes at least one processor; and at least one memoryincluding code which, when executed by the at least one processor,provides operations including generating, by the system, a first reportincluding analyte data obtained from a host-patient associated with areceiver and excluding patient identifying information identifyinghost-patient, when in a first sharing mode; generating, by the system, asecond report including the analyte data obtained from the host-patientassociated with the receiver and including patient identifyinginformation identifying the host-patient, when in a second sharing mode;and generating, by the system during a specified lifetime, a thirdreport including the analyte data obtained from the host-patientassociated with the receiver, when in a third sharing mode.

Example 68 includes the system of example 67, in which the first sharingmode includes triggering a data upload to the server to include theanalyte data and exclude the patient identifying information identifyingthe host-patient.

Example 69 includes the system of example 67, in which the first sharingmode is triggered when the receiver providing the data is not registeredwith the system.

Example 70 includes the system of example 67, in which the first sharingmode is triggered when the receiver providing the data is not logged inand/or authenticated by the system.

Example 71 includes the system of example 67, wherein the second sharingmode includes triggering a data upload to the system to include theanalyte data and include the patient identifying information identifyingthe host-patient.

Example 72 includes the system of example 67, in which the secondsharing mode is triggered when the receiver providing the data isregistered with the system.

Example 73 includes the system of example 67, in which the secondsharing mode is triggered when the receiver providing the data is notlogged in and/or authenticated by the system.

Example 74 includes the system of example 67, wherein the third sharingmode includes providing a share code to enable sharing of the generatedreport during the specified lifetime.

Example 75 includes the system of example 74, wherein the share codecomprises a checksum portion, a password portion, and an identifierportion indicative of the host-patient.

Example 76 includes the system of example 67, wherein the third sharingmode is triggered when a share code is received at the system.

Example 77 includes the system of example 67, further including sendingat least one of the first report, the second report, and/or the thirdreport.

Example 78 includes the system of example 67, further including sendingto the receiver an indication regarding whether to include or excludethe patient identifying information.

Example 79 includes the system of example 67, in which the systemcomprises at least one of a server or a secure server.

In some embodiments in accordance with the present technology (example80), a non-transitory computer readable storage medium including programcode which, when executed by at least one processor, causes operationsincluding generating, by a server, a first report including analyte dataobtained from a host-patient associated with a receiver and excludingpatient identifying information identifying host-patient, when in afirst sharing mode; generating, by the server, a second report includingthe analyte data obtained from the host-patient associated with thereceiver and including patient identifying information identifying thehost-patient, when in a second sharing mode; and generating, by theserver during a specified lifetime, a third report including the analytedata obtained from the host-patient associated with the receiver, whenin a third sharing mode.

In some embodiments in accordance with the present technology (example81), an apparatus includes means for generating a first report includinganalyte data obtained from a host-patient associated with a receiver andexcluding patient identifying information identifying host-patient, whenin a first sharing mode; means for generating a second report includingthe analyte data obtained from the host-patient associated with thereceiver and including patient identifying information identifying thehost-patient, when in a second sharing mode; and means for generating,during a specified lifetime, a third report including the analyte dataobtained from the host-patient associated with the receiver, when in athird sharing mode.

Various implementations of the subject matter described herein may berealized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof. Thecircuitry may be affixed to a printed circuit board (PCB), or the like,and may take a variety of forms, as noted. These various implementationsmay include implementation in one or more computer programs that areexecutable and/or interpretable on a programmable system including atleast one programmable processor, which may be special or generalpurpose, coupled to receive data and instructions from, and to transmitdata and instructions to, a storage system, at least one input device,and at least one output device.

These computer programs (also known as programs, software, softwareapplications, or code) include machine instructions for a programmableprocessor, and may be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the term “machine-readable medium” refers toany non-transitory computer program product, apparatus and/or device(e.g., magnetic discs, optical disks, memory, Programmable Logic Devices(PLDs)) used to provide machine instructions and/or data to aprogrammable processor, including a machine-readable medium thatreceives machine instructions.

To provide for interaction with a user, the subject matter describedherein may be implemented on a computer having a display device (e.g., aCRT (cathode ray tube) or LCD (liquid crystal display) monitor) fordisplaying information to the user and a keyboard and a pointing device(e.g., a mouse or a trackball) by which the user may provide input tothe computer. Other kinds of devices may be used to provide forinteraction with a user as well; for example, feedback provided to theuser may be any form of sensory feedback (e.g., visual feedback, audiblefeedback, or tactile feedback); and input from the user may be receivedin any form, including acoustic, speech, or tactile input.

The subject matter described herein may be implemented in a computingsystem that includes a back-end component (e.g., as a data server), orthat includes a middleware component (e.g., an application server), orthat includes a front-end component (e.g., a client computer having agraphical user interface or a Web browser through which a user mayinteract with an implementation of the subject matter described herein),or any combination of such back-end, middleware, or front-endcomponents. The components of the system may be interconnected by anyform or medium of digital data communication (e.g., a communicationnetwork). Examples of communication networks include a local areanetwork (“LAN”), a wide area network (“WAN”), and the Internet.

Although a few variations have been described in detail above, othermodifications are possible. For example, while the descriptions ofspecific implementations of the current subject matter discuss analyticapplications, the current subject matter is applicable to other types ofsoftware and data services access as well. Moreover, although the abovedescription refers to specific products, other products may be used aswell. In addition, the logic flows depicted in the accompanying figuresand described herein do not require the particular order shown, orsequential order, to achieve desirable results. Other implementationsmay be within the scope of the following claims.

What is claimed is:
 1. A method comprising: sending a message to aserver, wherein the message includes a request for a share code toenable another user to access, via a first computer, analyte dataobtained from a host-patient associated with a receiver and/or ananalyte report for the host-patient associated with the receiver;receiving, in response to the sending, the share code generated by theserver, wherein the share code comprises a checksum portion, a passwordportion, and an identifier portion indicative of the host-patient;generating a user interface view including the share code; anddisplaying the user interface view including the share code, wherein theshare code enables the other user to access, via the first computer, theanalyte data and/or the analyte report.
 2. The method of claim 1,further comprising: providing, by the first computer including anapplication, the share code to the server.
 3. The method of claim 2,wherein the application comprises a downloaded application and/or abrowser that accesses, via a wired connection and/or wirelessconnection, the server.
 4. The method of claim 2, wherein the providingcomprises at least one of: entering the share code at a webpagegenerated by the server; or sending to the server another messageincluding the share code.
 5. The method of claim 2, further comprising:checking, by the server, the share code to determine whether an accountassociated with the host-patient indicates that the share codeauthorizes report generation at the first computer.
 6. The method ofclaim 5, wherein the checking further comprises: checking the checksumportion of the share code; checking the password portion of the sharecode, when the checksum is valid; and verifying the identity portion ofthe share code by checking whether the identity portion maps to theaccount associated with the host-patient, when the checksum and passwordportion are valid.
 7. The method of claim 6, wherein the verifyingfurther comprises determining whether a lifetime for the share code hasexpired.
 8. The method of claim 7, wherein the lifetime is selected bythe host-patient and/or configured as a default time.
 9. The method ofclaim 5, further comprising: generating, by the server, the analytereport, when the checking determines that report generation isauthorized for presentation at the first computer.
 10. The method ofclaim 1, further comprising: triggering the sending of the request forthe share code, when the host-patient accesses a share code request iconpresented on webpage generated by the server.
 11. The method of claim 1,wherein a third sharing mode comprises enabling the other user toaccess, via the first computer, the analyte data obtained fromhost-patient associated with the receiver and/or the analyte report forthe host-patient associated with the receiver.
 12. The method of claim1, further comprising: uploading, when in a first sharing mode, to theserver the analyte data obtained from the host-patient, wherein theanalyte data comprises continuous glucose sensor data and patientidentifying information identifying host-patient.
 13. The method ofclaim 12, wherein the uploading to the server further comprisestransmitting the analyte data via at least one of a wired link, acellular data link, a wireless local area network link, and/or aBluetooth link.
 14. The method of claim 12, wherein the uploading isperformed by the receiver configured to wirelessly receive at least thecontinuous glucose sensor data from a continuous glucose sensor affixedto the host-patient.
 15. The method of claim 12, wherein the uploadingis via a remote computer.
 16. The method of claim 12, wherein theuploading is triggered when the receiver couples via at a wiredconnection and/or a wireless connection to the remote computer that isauthenticated by the server.
 17. The method of claim 16, wherein theauthentication comprises a login to an account associated with thehost-patient.
 18. The method of claim 12, further comprising:generating, for presentation at the remote computer, the analyte report,wherein the analyte report comprises the analyte data and patientidentifying information identifying the host-patient.
 19. The method ofclaim 1, further comprising: uploading, when in a second sharing mode,to the server the analyte data obtained from the host-patient, whereinthe analyte data includes continuous glucose sensor data and excludespatient identifying information identifying the host-patient.
 20. Themethod of claim 19, wherein the receiver excludes the patientidentifying information by at least one of removing, masking, orencrypting the patient identifying information.
 21. The method of claim19, wherein the uploading further comprises transmitting, by thereceiver, the analyte data via at least one of a wired link, a cellulardata link, a wireless local area network link, and/or a Bluetooth link.22. The method of claim 19, wherein the uploading is via the firstcomputer comprising a transient computer, wherein the transient computeris not logged into an account associated with host-patient.
 23. Themethod of claim 22, wherein the uploading is triggered by at least oneof: coupling the receiver via at a wired connection and/or wirelessconnection to the transient computer; and receiving an indication of aselection of an icon on a webpage, wherein the icon represents thesecond sharing mode, wherein the second sharing mode enables the otheruser to access the analyte data obtained from the host-patientassociated with the receiver and/or the analyte report for thehost-patient associated with the receiver, wherein the second sharingmode inhibits sharing of the patient identifying information identifyingthe host-patient.
 24. The method of claim 19, further comprising:triggering, when in the second sharing mode, the uploading by sending asecond sharing mode upload message from the server to the transientcomputer and/or the receiver.
 25. The method of claim 24, furthercomprising: generating the analyte report for presentation at thetransient computer, when the second sharing mode upload message isreceived.